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Quality-of-Service Option for Proxy Mobile IPv6 
Abstract 


This specification defines a new mobility option, the Quality-of- 
Service (QoS) option, for Proxy Mobile IPv6. This option can be used 
by the local mobility anchor and the mobile access gateway for 
negotiating Quality-of-Service parameters for a mobile node’s IP 
flows. The negotiated QoS parameters can be used for QoS policing 
and marking of packets to enforce QoS differentiation on the path 
between the local mobility anchor and the mobile access gateway. 
Furthermore, making QoS parameters available on the mobile access 
gateway enables mapping of these parameters to QoS rules that are 
specific to the access technology and allows those rules to be 
enforced on the access network using access-technology-specific 
approaches. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7222. 
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Copyright (c) 2014 IETF Trust and the persons identified as the 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
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1. Introduction 


Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to 
enable network-based mobility management for mobile nodes (MNs). 
Users can access IP-based services from their mobile device by using 


various radio access technologies. The currently supported mobile 
standards have adequate support for QoS-based service differentiation 
for subscriber traffic in cellular radio access networks. QoS 


policies are typically controlled by a policy control function, 
whereas the policies are enforced by one or more gateways in the 
infrastructure, such as the local mobility anchor (LMA) and the 
mobile access gateway (MAG), as well as by access network elements. 
Policy control and in-band QoS differentiation for access to the 
mobile operator network through alternative non-cellular access 
technologies are not supported in the currently specified standards. 
Although support for IP session handovers and IP flow mobility across 
access technologies already exists in cellular standards [TS23.402], 
QoS policy handovers across access technologies has not received much 
attention so far. 


Based on the deployment trends, Wireless LAN (WLAN) can be considered 
as the dominant alternative access technology to complement cellular 
radio access. Since the 802.1le extension [IEEE802.11e-2005] 
provides QoS extensions to WLAN, it is beneficial to apply QoS 
policies to WLAN access, which enables QoS classification of downlink 
as well as uplink traffic between a mobile node and its local 
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mobility anchor. For realizing this capability, this specification 
identifies three functional operations: 


(a) Maintaining QoS classification during a handover between 
cellular radio access and WLAN access by means of establishing QoS 
policies in the handover target access network, 


(b) mapping of QoS classes and associated policies between 
different access systems, and 


(c) establishment of QoS policies for new data sessions/flows, 
which are initiated while using WLAN access. 


This document specifies an extension to the PMIPv6 protocol [RFC5213] 
to establish QoS policies for a mobile node’s data traffic on the 
local mobility anchor and the mobile access gateway. QoS policies 
are conveyed in-band with PMIPv6é signaling using the specified QoS 
option and are enforced on the local mobility anchor for downlink 
traffic and on the mobile access gateway and its access network for 
the uplink traffic. The specified option allows association between 
IP session classification characteristics, such as a Differentiated 
Services Code Point (DSCP) [RFC2474], and the expected QoS class for 
the IP session. This document specifies fundamental QoS attributes 
that apply on a per-mobile-node, per-mobility-session, or per-flow 
basis. The specified attributes are not specific to any access 
technology but are compatible with the Third Generation Partnership 
Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications 
[IEEE802.11-2012]. 


Additional QoS attributes can be specified and used with the QoS 
option, e.g., to represent more specific descriptions of latency 
constraints or jitter bounds. The specification of such additional 
QoS attributes as well as the handling of QoS policies between the 
mobile access gateway and the access network are out of the scope of 
this specification. 


2. Conventions and Terminology 
2.1. Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2.2. Terminology 


All the mobility-related terms used in this document are to be 
interpreted as defined in the Proxy Mobile IPv6é specifications 
[RFC5213], [RFC5844], and [RFC7077]. Additionally, this document 
uses the following abbreviations: 


Aggregate Maximum Bit Rate (AMBR) 


AMBR defines the upper limit on the bit rate that can be provided 
by the network for a set of IP flows. IP packets within the flows 
exceeding the AMBR limit may be discarded by the rate-shaping 
function where the AMBR parameter is enforced. Variants of the 
"AMBR" term can be defined by restricting the target set of IP 
flows on which the AMBR is applied to a mobile node, mobility 
session, or flow direction. For example, Per-Mobile-Node 
Aggregate Maximum Downlink Bit Rate, Per-Mobile-Node Aggregate 
Maximum Uplink Bit Rate, Per-Mobility-Session Aggregate Maximum 
Downlink Bit Rate, and Per-Mobility-Session Aggregate Maximum 
Uplink Bit Rate are used in this document. 


Allocation and Retention Priority (AARP) 


AARP is used in congestion situations when there are insufficient 
resources for meeting all Service Requests. It is used primarily 
by the Admission Control function to determine whether a 
particular Service Request must be rejected due to lack of 
resources or honored by preempting an existing low-priority 
service. 


Differentiated Services Code Point (DSCP) 


In the Differentiated Services Architecture [RFC2474], packets are 
classified and marked to receive a particular per-hop forwarding 
behavior on nodes along their path based on the marking present on 
the packet. This marking on IPv4 and IPv6 packets that defines a 
specific per-hop behavior is known as DSCP. Refer to [RFC2474], 
[RFC2475], [RFC4594], and [RFC2983] for a complete explanation. 


Downlink (DL) Traffic 


The mobile node’s IP packets that the mobile access gateway 
receives from the local mobility anchor are referred to as the 
Downlink traffic. The "Downlink" term used in the QoS attribute 
definition is always from the reference point of the mobile node, 
and it implies traffic heading towards the mobile node. 
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Guaranteed Bit Rate (GBR) 


GBR denotes the assured bit rate that will be provided by the 
network for a set of IP flows. It is assumed that the network 
reserves the resources for supporting the GBR parameter. Variants 
of the "GBR" term can be defined by limiting the scope of the 
target IP flows on which the GBR is applied to a mobile node, 
mobility session, or flow direction. For example, Guaranteed 
Downlink Bit Rate and Guaranteed Uplink Bit Rate are used in this 
document. 


Mobility Session 


The term "mobility session" is defined in [RFC5213]. It refers to 
the creation or existence of state associated with the mobile 
node’s mobility binding on the local mobility anchor and on the 
mobile access gateway. 


QoS Service Request 


A QoS Service Request is a set of QoS parameters that are defined 
to be enforced on one or more mobile node’s IP flows. The 
parameters at the minimum include a DSCP marking and additionally 
may include Guaranteed Bit Rate or Aggregate Maximum Bit Rate. 
The Quality-of-Service option defined in this document represents 
a QoS Service Request. 


Service Identifier 


In some mobility architectures, multiple services within the same 
mobility service subscription are offered to a mobile node. Each 
of those services provide a specific service (for example, 
Internet Service and Voice Over IP Service) and has an identifier 
called "Service Identifier". 3GPP APN (Access Point Name) is an 
example of a Service Identifier. Refer to [RFC5149] for the 
definition of the Service Identifier and the mobility option used 
for carrying the Service Identifier. 


Uplink (UL) Traffic 


The mobile node’s IP packets that the mobile access gateway 
forwards to the local mobility anchor are referred to as the 
Uplink traffic. The "Uplink" term used in the QoS attribute 
definitions is based on the reference point of the mobile node, 
and it implies traffic originating from the mobile node. 
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3. Overview of QoS Support in Proxy Mobile IPv6 


The Quality-of-Service support in Proxy Mobile IPv6 specified in this 
document is based on the Differentiated Services Architecture 
([RFC2474] and [RFC2475]). The access and the home network in the 
Proxy Mobile IPv6 domain are assumed to be DiffServ-enabled, with 
every network node in the forwarding path for the mobile node’s IP 
traffic being DiffServ-compliant. The per-hop behavior for providing 
differential treatment based on the DiffServ marking in the packet is 
assumed to be supported in the Proxy Mobile IPv6 domain. 


The local mobility anchor in the home network and the mobile access 
gateway in the access network define the network boundary between the 
access and the home network. As the tunnel entry and exit points for 
the mobile node’s IP traffic, these entities are the logical choice 
for being chosen as the QoS enforcement points. The basic QoS 
functions such as marking, metering, policing, and rate-shaping on 
the mobile node’s IP flows can be enforced at these nodes. 


The local mobility anchor and the mobile access gateway can negotiate 
the Quality-of-Service parameters for a mobile node’s IP flows based 
on the signaling extensions defined in this document. The QoS 
services that can be enabled for a mobile node are for meeting both 
the quantitative performance requirements (such as Guaranteed Bit 
Rate) as well as for realizing relative performance treatment by way 
of class-based differentiation. The subscriber’s policy and the 
charging profile (for example, [TS22.115]) are key considerations for 
the mobility entities in the QoS service negotiation. The decision 
on the type of QoS services that are to be enabled for a mobile node 
is based on the subscriber profile and based on available network 
resources. The negotiated QoS parameters are used for providing QoS 
differentiation on the path between the local mobility anchor and the 
mobile access gateway. The signaling related to QoS services is 
strictly between the mobility entities and does not result in per- 
flow state or signaling to any other node in the network. 
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Figure 1: QoS Support 


Figure 1 illustrates the support of QoS services in a Proxy Mobile 
IPv6 domain. The local mobility anchor and the mobile access gateway 
have negotiated QoS parameters for the mobility sessions belonging to 
MN-1 and MN-2. The negotiated QoS parameters include a Per-Session- 
AMBR of 1 Mbps and 2 Mbps for MN-1 and MN-2 respectively. 
Furthermore, different IP flows from MN-1 and MN-2 are given 
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different QoS service treatment, for example, a GBR of 64 Kbps for 
Flow-1 and Flow-4 is assured, a DSCP marking enforcement of "Z" on 
Flow-6, and an MBR of 100 Kbps on Flow-5. 


SLs 


Quality-of-Service Option -- Usage Examples 


Use Case 1: Figure 2 illustrates a scenario where a local mobility 
anchor initiates a QoS Service Request to a mobile access gateway. 


(0) 


4+----- + 4+----- + 4+----- + 
| ma | | mac | | Ima | 
4+----- + 4+----- + 4+----- + 
| | 
---- MN Attach ----| | 
|------ PBU ------- >| 
<----- PBA -------- 


lo fe) 
| PMIPv6 Tunnel 
| 


| 

| 
(LMA initiates QoS Service eae | 
<----- UPN (QoS) 7] 
| 

| 

| 

=| 


(MAG proposes a revised QoS ares 
SSS UPA (Q0S’)-> 


| <----- UPN 
| ------ UPA ers -> 
QoS Rules J55 
Established <- | | QoS Rules ---| 
---| Established <-| | 
<----------------- >| | 


Figure 2: LMA-Initiated QoS Service Request 


(1) to (4): MAG detects the mobile node’s attachment to the access 
link and initiates the signaling with the local mobility anchor. 
Upon completing the signaling, the LMA and MAG establish the 
mobility session and the forwarding state. 


(5) to (8): The LMA initiates a QoS Service Request to the mobile 
access gateway. The trigger for this service can be based on a 
trigger from a policy function, and the specific details of that 
trigger are outside the scope of this document. The LMA sends an 
Update Notification (UPN) message [RFC7077] to the MAG. The 
message includes the QoS option (Section 4.1), which includes a 
set of QoS parameters. On determining that it cannot support the 
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requested QoS Service Request for that mobile, 


Update Notification Acknowledgement (UPA) message. 
contains a revised QoS option with an updated set of QoS 


attributes. 


o (9) 


to (11): 


Request. Fur 


mechanisms) 


Use Case 2: 


May 2014 


the MAG sends an 
The message 


The LMA accepts the revised QoS Service Request by 
sending a new Update Notification message including the updated 
QoS option. 


Upon successfully negotiating a QoS Service Request, 
the MAG and the LMA install the QoS rules for that Service 
thermore, the MAG (using access-technology-specific 


installs the QoS rules on the access network. 


Figure 3 illustrates a scenario where a mobile access 


gateway initiates a QoS Service Request to a local mobility anchor. 


+----- + +----- + +----- + 
| MN | | MAG | | LMA | 
+----- + +----- + +----- + 

1) |---- MN Attach ----| | 

2) | |------ PBU ------- >| 

3) | <----- PBA -------- | 

4) | [o o | 

| | PMIPv6 Tunnel | 
| (MAG initiates QoS Service Request) | 

Do =- PBU (QoS) --> 

6) <----- PBA (QoS) --- 

| QoS Rules ---| 

7) | Established <-| | QoS Rules ---| 

8) | ---| Established <-| | 

9) [s----------------- >| | 

Figure 3: MAG-Initiated QoS Service Request 

o (1) to (4): MAG detects the mobile node’s attachment to the access 
link and initiates the signaling with the local mobility anchor. 
Upon completing the signaling, the LMA and MAG establish the 
mobility session and the forwarding state. 

o (5) to (6): The MAG initiates a QoS Service Request to the local 
mobility anchor. The trigger for this service can be based on a 
trigger from the mobile node using access-technology-specific 
mechanisms. The specific details of that trigger are outside the 
scope of this document. The MAG sends a Proxy Binding Update 
(PBU) message [RFC5213] to the LMA. The message includes the QoS 
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option (Section 4.1), which includes a set of QoS parameters. The 
LMA agrees to the proposed QoS Service Request by sending a Proxy 
Binding Acknowledgement (PBA) message. 


(7) to (9): Upon successfully negotiating a QoS Service Request, 
the MAG and the LMA install the QoS rules for that Service 
Request. Furthermore, the MAG using access-technology-specific 
mechanisms installs the QoS rules on the access network. 


Quality-of-Service Attributes -- Usage Examples 


This section identifies the use cases where the Quality-of-Service 
option (Section 4.1) and its attributes (Section 4.2) defined in this 
document are relevant. 


(0) 


The subscription policy offered to a mobile subscriber requires 
the service provider to enforce Aggregate Maximum Bit Rate (AMBR) 
limits on the subscriber's IP traffic. The local mobility anchor 
and the mobile access gateway negotiate the uplink and the 
downlink AMBR values for the mobility session and enforce them in 
the access and the home network. The QoS option (Section 4.1) 
with the QoS attributes Per-Session-Agg-Max-DL-Bit-Rate 

(Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate 

(Section 4.2.4) is used for this purpose. 


In Community Wi-Fi deployments, the residential gateway 
participating in the Wi-Fi service is shared between the home user 
and the community Wi-Fi users. In order to ensure the home user's 
Wi-Fi service is not impacted because of the community Wi-Fi 
service, the service provider enables Guaranteed Bit Rate (GBR) 
for the home user’s traffic. The QoS option (Section 4.1) with 
the QoS attributes Guaranteed-DL-Bit-Rate (Section 4.2.8) and 
Guaranteed-UL-Bit-Rate (Section 4.2.9) is used for this purpose. 


A mobile user using the service provider’s Voice over IP 
infrastructure establishes a VoIP call with some other user in the 
network. The negotiated call parameters for the VoIP call require 
a dedicated bandwidth of certain fixed value for the media flows 
associated with that VoIP session. The application function in 
the VoIP infrastructure notifies the local mobility anchor to 
enforce the GBR limits on that IP flow identified by the flow 
definition. The QoS option (Section 4.1) with the QoS attributes 
Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate 
(Section 4.2.9), and QoS-Traffic-Selector (Section 4.2.10) is used 
for this purpose. 
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o An emergency service may require network resources in conditions 
when the network resources have been fully allocated to other 


users and the network may be experiencing severe congestion. In 
such cases, the service provider may want to revoke resources that 
have been allocated and reassign them to emergency services. The 


local mobility anchor and the mobile access gateway negotiate 
Allocation and Retention Priority (AARP) values for the IP 
sessions associated with the emergency applications. The QoS 
option (Section 4.1) with the QoS attribute Allocation-Retention-— 
Priority (Section 4.2.5) is used for this purpose. 


4. Protocol Messaging Extensions 
4.1. Quality-of-Service Option 


The Quality-of-Service option is a mobility header option used by 
local mobility anchors and mobile access gateways for negotiating QoS 
parameters associated with a mobility session. This option can be 
carried in Proxy Binding Update (PBU) [RFC5213], Proxy Binding 
Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077] 
and Update Notification Acknowledgement (UPA) [RFC7077] messages. 
There can be more than one instance of the Quality-of-Service option 
in a single message. Each instance of the Quality-of-Service option 
represents a specific QoS Service Request. 


The alignment requirement for this option is 4n. 


0 1 2 3 
012345678°9012345678901234567890 1 
—+-4-4+-4+-4+-4-4-4-4-4-4-t-t-t-t-t-4t-4+-4+-4+-+-+-4+-4-4+-4+-4-4-4-4-4-4 
Type | Length | SR-ID | TC | 
—+-+-4+-4+-+4+-4+-4-4-4-4-4-t-t-t-t-t-4t-4t-4+-4+-+-+-4+-4+-4+-4+-4-4-4-4-4-4 
oc | Reserved | 
—+-+-4-4-4+-4+-4-4-4-4-4-t-t-t-t-t-4t-4t-4+-4+-+-+-4+-4+-4+-4+-4-4-4-4-4-4 
QoS Attribute (s) x 
t—t-+-+-4+-4+-4+-4+-4+-4+-4+-+-+-4-4-4-4+-4-4-4-4-4-4-4-4-4-t-t-t-t-t-4-4 


: +— +— + 


Figure 4: QoS Option 
o Type: 58 


o Length: 8-bit unsigned integer indicating the length of the option 
in octets, excluding the Type and Length fields. 


o Service Request Identifier (SR-ID): An 8-bit unsigned integer used 
for identifying the QoS Service Request. Its uniqueness is within 
the scope of a mobility session. The local mobility anchor always 
allocates the Service Request Identifier. When a new QoS Service 


Liebsch, et al. Standards Track [Page 12] 


RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 


Request is initiated by a mobile access gateway, the Service 
Request Identifier in the initial request message is set toa 
value of (0), and the local mobility anchor allocates a Service 
Request Identifier and includes it in the response. For any new 
QoS Service Requests initiated by a local mobility anchor, the 
Service Request Identifier is set to the allocated value. 


o Traffic Class (TC): Traffic Class consists of a 6-bit DSCP field 
followed by a 2-bit reserved field. 


Differentiated Services Code Point (DSCP) 


A 6-bit unsigned integer indicating the code point value, as 
defined in [RFC2475] to be used for the mobile node’s IP flows. 
When this DSCP marking needs to be applied only for a subset of 
a mobile node’s IP flows, there will be a Traffic Selector 
attribute (Section 4.2.10) in the option, which provides the 
flow selectors. In the absence of any such Traffic Selector 
attribute, the DSCP marking applies to all the IP flows 
associated with the mobility session. 


Reserved 


The last two bits in the Traffic Class field are currently 
unused. These bits MUST be initialized by the sender to (0) 
and MUST be ignored by the receiver. 


o Operational Code (OC): l-octet Operational code indicates the type 
of QoS request. 


RESPONSE: (0) 
Response to a QoS request 


ALLOCATE: (1) 
Request to allocate QoS resources 


DE-ALLOCATE: (2) 
Request to de-Allocate QoS resources 


MODIFY: (3) 


Request to modify QoS parameters for a previously negotiated 
QoS Service Request 


QUERY: (4) 


Query to list the previously negotiated QoS Service Requests 
that are still active 
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NEGOTIATE: (5) 
Response to a QoS Service Request with a counter QoS proposal 


Reserved: (6) to (255) 
Currently not used. Receiver MUST ignore the option received 
with any value in this range. 


o Reserved: This field is unused for now. The value MUST be 
initialized to a value of (0) by the sender and MUST be ignored by 
the receiver. 


o QoS Attribute(s): Zero or more TLV-encoded QoS attributes. The 
format of the QoS attribute is defined in Section 4.2. The 
interpretation and usage of the QoS attribute is based on the 
value in the Type field. 


4.2. Quality-of-Service Attributes 


This section identifies the format of a Quality-of-Service attribute. 
A QoS attribute can be included in the Quality-of-Service option 
defined in Section 4.1. This section identifies the QoS attributes 
defined by this specification. 


0 1 2 3 
Oth 2 3? As O26 PB. 9°). A 23 4: S 6 T89 0 3 A: 6 7778. g <0. a. 
$ototatatatatitotototitititatatatatititotititotitatatatatitototot 
| Type | Length | Value j 
+-+-+-+-+-+-++- +++ 


Figure 5: Format of a Quality-of-Service Attribute 


o Type: 8-bit unsigned integer indicating the type of the QoS 
attribute. This specification reserves the following values. 


(0) - Reserved 
This value is reserved and cannot be used 


(1) - Per-MN-Agg-Max-DL-Bit-Rate 
This QoS attribute, Per-Mobile-Node Aggregate Maximum Downlink 
Bit Rate, is defined in Section 4.2.1. 


(2) - Per-MN-Agg-Max-UL-Bit-Rate 
This QoS attribute, Per-Mobile-Node Aggregate Maximum Uplink 
Bit Rate, is defined in Section 4.2.2. 


(3) - Per-Session-Agg-Max-DL-Bit-Rate 


This QoS attribute, Per-Mobility-Session Aggregate Maximum 
Downlink Bit Rate, is defined in Section 4.2.3. 
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(4) - Per-Session-Agg-Max-UL-Bit-Rate 
This QoS attribute, Per-Mobility-Session Aggregate Maximum 
Uplink Bit Rate, is defined in Section 4.2.4. 


(5) - Allocation-Retention-Priority 
This QoS attribute, Allocation and Retention Priority, is 
defined in Section 4.2.5. 


(6) - Aggregate-Max-DL-Bit-Rate 
This QoS attribute, Aggregate Maximum Downlink Bit Rate, is 
defined in Section 4.2.6. 


(7) - Aggregate-Max-UL-Bit-Rate 
This QoS attribute, Aggregate Maximum Uplink Bit Rate, is 
defined in Section 4.2.7. 


(8) - Guaranteed-DL-Bit-—Rate 
This QoS attribute, Guaranteed Downlink Bit Rate, is defined in 


Section 4.2.8. 


(9) - Guaranteed-UL-Bit-—Rate 
This QoS attribute, Guaranteed Uplink Bit Rate, is defined in 
Section 4.2.9. 


(10) - QoS-Traffic-Selector 
This QoS attribute, QoS Traffic Selector, is defined in 
Section 4.2.10. 


(11) - QoS-Vendor-Specific—Attribute 
This QoS attribute, QoS Vendor-Specific Attribute, is defined 
in Section 4.2.11. 


(12) to (254) - Reserved 
These values are reserved for future allocation. 


(255) - Reserved 
This value is reserved and cannot be used. 


o Length: 8-bit unsigned integer indicating the number of octets 
needed to encode the Value, excluding the Type and Length fields. 


o Value: The format of this field is based on the Type value. 
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4.2.1. Per-Mobile-Node Aggregate Maximum Downlink Bit Rate 


This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum 
downlink bit rate for a mobile node. It is a variant of the "AMBR" 
term defined in Section 2.2. This value is an aggregate across all 
mobility sessions associated with that mobile node. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by a 
local mobility anchor, it indicates the maximum aggregate downlink 
bit rate that is being requested for the mobile node at the peer. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the maximum aggregate downlink bit rate that the peer 
agrees to offer. 


If multiple mobility sessions are established for a mobile node, 
through multiple mobile access gateways with sessions anchored either 
on a single local mobility anchor or spread out across multiple local 
mobility anchors, then it depends on the operator’s policy and the 
specific deployment as to how the total bandwidth for the mobile node 
on each MAG-LMA pair is computed. 


When a QoS option includes both the Per-MN-Agg-Max-DL-Bit-Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the QoS-Traffic-Selector attribute does not apply to this 
attribute. 


0 dl 2 3 
01-23. 4 5-6 7 89-0 T 234-5 6-7-8 OD 2 8 45 6 T 8 9-20 L 
—4+-4-4-4-4-4-4-4-4-4+-4-4-4-4+-4+-4+-4+-4-4+-4-4-4-4+-4+-4-4-4-4-4-4-4-4 
Type | Length | Reserved 
—4+-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4-4-4-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4 
Per-MN-Agg-Max-DL-Bit-Rate | 
—4+-4-4-4-4-4-4-4-4-4+-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4 


+—+—+ 


o Type: 1 


o Length: The length in octets of the attribute, excluding the Type 
and Length fields. This value is set to (6). 
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o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Per-MN-Agg-Max-DL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the aggregate maximum downlink bit rate that is 
requested/allocated for all the mobile node’s IP flows. The 
measurement units for Per-MN-Agg-Max-—DL-Bit-—Rate are bits per 
second. 


4.2.2.  Per-Mobile-Node Aggregate Maximum Uplink Bit Rate 


This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum 
uplink bit rate for the mobile node. It is a variant of the "AMBR" 
term defined in Section 2.2. This value is an aggregate across all 
mobility sessions associated with that mobile node. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the maximum aggregate uplink 
bit rate that is being requested for the mobile node at the peer. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the maximum aggregate uplink bit rate that the peer agrees 
to offer for that mobile node. 


If multiple mobility sessions are established for a mobile node, 
through multiple mobile access gateways with sessions anchored either 
on a single local mobility anchor or spread out across multiple local 
mobility anchors, then it depends on the operator’s policy and the 
specific deployment as to how the total bandwidth for the mobile node 
on each MAG-LMA pair is computed. 


When a QoS option includes both the Per-MN-Agg-Max-UL-Bit-Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the QoS-Traffic-Selector attribute does not apply to this 
attribute. 
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(0) 1 2 3 
0 1.2-3 4 5-6 7 8 9 0°11 23.4 56A 8g 9 0 1234-5 678 9 0 1 
—4+-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4+-4-4+-4-4-4+-4+-4+-4+-4-4+-4-4-4-4-4-4-4 
Type | Length | Reserved 
—4+-4-4-4-4-4-4-4-4-4-4+-4+-4-4-4+-4-4+-4-4-4+-4+-4+-4+-4-4+-4-4-4-4-4-4-4 
Per-MN-Agg-Max-UL-Bit-Rate | 
—4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4+-4+-4+-4-4-4-4+-4+-4+-4+-4-4-4-4-4-4-4-4 


+—+—+ 


o Type: 2 


o Length: The length in octets of the attribute, excluding the Type 
and Length fields. This value is set to (6). 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Per-MN-Agg-Max-UL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the aggregate maximum uplink bit rate that is requested/ 
allocated for the mobile node’s IP flows. The measurement units 
for Per-MN-Agg-Max-UL-Bit-Rate are bits per second. 


4.2.3. Per-Mobility-Session Aggregate Maximum Downlink Bit Rate 


This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the 
maximum downlink bit rate for the mobility session. It is a variant 
of the "AMBR" term defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the maximum aggregate 
downlink bit rate that is being requested for that mobility session. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the maximum aggregate downlink bit rate that the peer 
agrees to offer for that mobility session. 


When a QoS option includes both the Per-Session-Agg-Max-DL-Bit-Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the QoS-Traffic-Selector attribute does not apply to this 
attribute. 
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0 d 2 3 
01234567890123456789012345678<901 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Length |s|E| Reserved 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Per-Session-Agg-Max-DL-Bit-Rate 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+ 


o Type: 3 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Service (S) flag: This flag is used for extending the scope of the 
target flows for Per-Session-Agg-Max-DL-Bit-Rate to the mobile 
node’s other mobility sessions sharing the same Service 
Identifier. 3GPP Access Point Name (APN) is an example of a 
Service Identifier, and that identifier is carried using the 
Service Selection mobility option [RFC5149]. 


* When the (S) flag is set to a value of (1), then the Per- 
Session-Agg-Max-—DL-Bit-—Rate is measured as an aggregate across 
all the mobile node’s other mobility sessions sharing the same 
Service Identifier associated with this mobility session. 


* When the (S) flag is set to a value of (0), then the target 
flows are limited to the current mobility session. 


* The (S) flag MUST NOT be set to a value of (1) when there is no 
Service Identifier associated with the mobility session. 


o Exclude (E) flag: This flag is used to request that the downlink 
flows for which the network is providing Guaranteed-Bit-—Rate 
service be excluded from the target IP flows for which Per- 
Session-Agg-Max-DL-Bit-—Rate is measured. 


* When the (E) flag is set to a value of (1), then the request is 
to exclude the IP flows for which Guaranteed-DL-Bit-—Rate 
(Section 4.2.8) is negotiated from the flows for which Per- 
Session-Agg-Max-DL-Bit-—Rate is measured. 


* When the (E) flag is set to a value of (0), then the request is 


not to exclude any IP flows from the target IP flows for which 
Per-—Session-Agg-Max-—DL-Bit-—Rate is measured. 
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* When the (S) flag and (E) flag are both set to a value of (1), 
then the request is to exclude all the IP flows sharing the 
Service Identifier associated with this mobility session from 
the target flows for which Per-Session-Agg-Max-DL-Bit-Rate is 
measured. 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Per-Session-Agg-Max-DL-Bit-Rate: This is a 32-bit unsigned integer 
that indicates the aggregate maximum downlink bit rate that is 
requested/allocated for all the IP flows associated with that 
mobility session. The measurement units for Per-Session-Agg-Max- 
DL-Bit-Rate are bits per second. 


4. Per-Mobility-Session Aggregate Maximum Uplink Bit Rate 


This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the 
maximum uplink bit rate for the mobility session. It is a variant of 
the "AMBR" term defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message [RFC7077] 
sent by the local mobility anchor, it indicates the maximum aggregate 
uplink bit rate that is being requested for that mobility session. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement [RFC7077] 
message, it indicates the maximum aggregate uplink bit rate that the 
peer agrees to offer for that mobility session. 


When a QoS option includes both the Per-Session-Agg-Max-UL-Bit-Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the QoS-Traffic-Selector attribute does not apply to this 
attribute. 


0 1 2 3 
012345678901234567890123456789041 
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| Per-Session-Agg-Max-UL-Bit-Rate 
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o Type: 4 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Service (S) flag: This flag is used for extending the scope of the 
target flows for Per-Session-Agg-Max-UL-Bit-Rate to the mobile 
node’s other mobility sessions sharing the same Service 
Identifier. 3GPP Access Point Name (APN) is an example of a 
Service Identifier, and that identifier is carried using the 
Service Selection mobility option [RFC5149]. 


* When the (S) flag is set to a value of (1), then the Per- 
Session-Agg-Max-UL-Bit-—Rate is measured as an aggregate across 
all the mobile node’s other mobility sessions sharing the same 
Service Identifier associated with this mobility session. 


* When the (S) flag is set to a value of (0), then the target 
flows are limited to the current mobility session. 


* The (S) flag MUST NOT be set to a value of (1) when there is no 
Service Identifier associated with the mobility session. 


o Exclude (E) flag: This flag is used to request that the uplink 
flows for which the network is providing Guaranteed-Bit-—Rate 
service be excluded from the target IP flows for which Per- 
Session-Agg-Max-UL-Bit-—Rate is measured. 


* When the (E) flag is set to a value of (1), then the request is 
to exclude the IP flows for which Guaranteed-UL-Bit-Rate 
(Section 4.2.9) is negotiated from the flows for which Per- 
Session-Agg-Max-UL-Bit-—Rate is measured. 


* When the (E) flag is set to a value of (0), then the request is 
not to exclude any IP flows from the target IP flows for which 
Per-Session-Agg-Max-UL-Bit-—Rate is measured. 


* When the (S) flag and (E) flag are both set to a value of (1), 
then the request is to exclude all the IP flows sharing the 
Service Identifier associated with this mobility session from 
the target flows for which Per-Session-Agg-Max-UL-Bit-Rate is 
measured. 


o Reserved: This field is unused for now. The value MUST be 


initialized by the sender to 0 and MUST be ignored by the 
receiver. 
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o Per-Session-Agg-Max-UL-Bit-Rate: This is a 32-bit unsigned integer 
that indicates the aggregate maximum uplink bit rate that is 
requested/allocated for all the IP flows associated with that 
mobility session. The measurement units for Per-Session-Agg-Max-— 
UL-Bit-Rate are bits per second. 


4.2.5. Allocation and Retention Priority 


This attribute, Allocation-Retention-Priority, represents allocation 
and retention priority for the mobility session or a set of IP flows. 
It is defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When the QoS option includes both the Allocation-Retention-Priority 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the Allocation-Retention-Priority attribute is to be applied at 
a flow level. The traffic selector in the QoS-Traffic-—Selector 
attribute identifies the target flows. 


When the QoS option including the Allocation-Retention-Priority 
attribute does not include the QoS-Traffic-Selector attribute 
(Section 4.2.10), then the Allocation-Retention-Priority attribute is 
to be applied to all the IP flows associated with that mobility 
session. 


0 1 2 3 
0T 23 Ae P-E gO- 2 3A S 6 T7 8°90 T2 3A D6 T890 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HH 
Type | Length | Reserved | PL |pc |Pv | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HH 


+—+ 


o Type: 5 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (2). 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Priority-Level (PL): This is a 4-bit unsigned integer value. It 
is used to decide whether a mobility session establishment or 
modification request can be accepted; this is typically used for 
admission control of Guaranteed Bit Rate traffic in case of 
resource limitations. The priority level can also be used to 
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decide which existing mobility session to preempt during resource 
limitations. The priority level defines the relative timeliness 
of a resource request. 


Values 1 to 15 are defined, with value 1 as the highest level of 
priority. 


Values 1 to 8 should only be assigned for services that are 
authorized to receive prioritized treatment within an operator 
domain. Values 9 to 15 may be assigned to resources that are 
authorized by the home network and thus applicable when a mobile 
node is roaming. 


o Preemption-Capability (PC): This is a 2-bit unsigned integer 
value. It defines whether a service data flow can get resources 
that were already assigned to another service data flow with a 
lower priority level. The following values are defined: 


Enabled (0): This value indicates that the service data flow is 
allowed to get resources that were already assigned to another 
IP data flow with a lower priority level. 


Disabled (1): This value indicates that the service data flow 
is not allowed to get resources that were already assigned to 
another IP data flow with a lower priority level. The values 
(2) and (3) are reserved. 


o Preemption-Vulnerability (PV): This is a 2-bit unsigned integer 
value. It defines whether a service data flow can lose the 
resources assigned to it in order to admit a service data flow 
with a higher priority level. The following values are defined: 


Enabled (0): This value indicates that the resources assigned 
to the IP data flow can be preempted and allocated to a service 
data flow with a higher priority level. 


Disabled (1): This value indicates that the resources assigned 
to the IP data flow shall not be preempted and allocated to a 
service data flow with a higher priority level. The values (2) 
and (3) are reserved. 


4.2.6. Aggregate Maximum Downlink Bit Rate 
This attribute, Aggregate-Max-DL-Bit-Rate, represents the maximum 


downlink bit rate for the mobility session. It is a variant of the 
"AMBR" term defined in Section 2.2. 
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This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the maximum aggregate bit 
rate for downlink IP flows that is being requested. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the maximum aggregate downlink bit rate that the peer 
agrees to offer. 


When a QoS option includes both the Aggregate-Max-DL-Bit-Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a 
flow level, and the traffic selectors present in the QoS-Traffic-— 
Selector attribute identify those target flows. 


When the QoS option that includes the Aggregate-Max-—DL-Bit-Rate 
attribute does not include the QoS-Traffic-Selector attribute 
(Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to 
be applied to all the IP flows associated with the mobility session. 


0 1 2 3 
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-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Length | Reserved 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Aggregate-Max-DL-Bit-Rate 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+—+ 


o Type: 6 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Aggregate-Max-DL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the aggregate maximum downlink bit rate that is 
requested/allocated for downlink IP flows. The measurement units 
for Aggregate-Max-DL-Bit-Rate are bits per second. 
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4.2.7. Aggregate Maximum Uplink Bit Rate 


This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum 
uplink bit rate for the mobility session. It is a variant of the 
"AMBR" term defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the maximum aggregate uplink 
bit rate that is being requested. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the maximum aggregate uplink bit rate that the peer agrees 
to offer. 


When a QoS option includes both the Aggregate-Max-UL-Bit-—Rate 
attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), 
then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a 
flow level, and the traffic selectors present in the QoS-Traffic-— 
Selector attribute identify those target flows. 


When the QoS option that includes the Aggregate-Max-UL-Bit-—Rate 
attribute does not include the QoS-Traffic-Selector attribute 
(Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to 
be applied to all the IP flows associated with the mobility session. 
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+—+—+ 


o Type: 7 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Reserved: This field is unused for now. The value MUST be 


initialized by the sender to 0 and MUST be ignored by the 
receiver. 
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Lie 


o Aggregate-Max-UL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the aggregate maximum uplink bit rate that is requested/ 
allocated for all the IP flows associated with that mobility 
session. The measurement units for Aggregate-Max-UL-Bit-Rate are 
bits per second. 


-8. Guaranteed Downlink Bit Rate 


This attribute, Guaranteed-DL-Bit-Rate, represents the assured bit 
rate on the downlink path that will be provided for a set of IP flows 
associated with a mobility session. It is a variant of the "GBR" 
term defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the guaranteed downlink bit 
rate that is being requested. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the guaranteed downlink bit rate that the peer agrees to 
offer. 


When a QoS option includes both the Guaranteed-DL-Bit-Rate attribute 
and the QoS-Traffic-Selector attribute (Section 4.2.10), then the 
Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level, 
and the traffic selectors present in the QoS-Traffic-—Selector 
attribute identify those target flows. 


When the QoS option that includes the Guaranteed-DL-Bit-Rate 
attribute does not include the QoS-Traffic-Selector attribute 
(Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be 
applied to all the IP flows associated with the mobility session. 


0 1 2 3 
o 23) Ae 6 PE BOO) WA 34 T a O 28 a 6? TB. 92:0. 1 
H toto totititotitatatatatatototitititititatatatatitotititotot-t-t 
Type | Length | Reserved 
Hato totitotitititatatatatitotititititititatatatitototitotot-t-t 
Guaranteed-DL-Bit-Rate 
-+-+-+-+-+-+-+-+-+-+-+ +H 
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Type: 8 
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es 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Guaranteed-DL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the guaranteed bandwidth in bits per second for downlink 
IP flows. The measurement units for Guaranteed-DL-Bit-Rate are 
bits per second. 


9. Guaranteed Uplink Bit Rate 


This attribute, Guaranteed-UL-Bit-Rate, represents the assured bit 
rate on the uplink path that will be provided for a set of IP flows 
associated with a mobility session. It is a variant of the "GBR" 
term defined in Section 2.2. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
only be a single instance of this attribute present in a QoS option. 


When this attribute is present in a Proxy Binding Update sent by a 
mobile access gateway or in an Update Notification message sent by 
the local mobility anchor, it indicates the guaranteed uplink bit 
rate that is being requested. 


When this attribute is present in a Proxy Binding Acknowledgement 
message or in an Update Notification Acknowledgement message, it 
indicates the guaranteed uplink bit rate that the peer agrees to 
offer. 


When a QoS option includes both the Guaranteed-UL-Bit-Rate attribute 
and the QoS-Traffic-Selector attribute (Section 4.2.10), then the 
Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level, 
and the traffic selectors present in the QoS-Traffic-—Selector 
attribute identify those target flows. 


When the QoS option that includes the Guaranteed-UL-Bit-Rate 
attribute does not include the QoS-Traffic-Selector attribute 
(Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be 
applied to all the IP flows associated with the mobility session. 
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o Type: 9 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. This value is set to (6). 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o Guaranteed-UL-Bit-Rate: This is a 32-bit unsigned integer that 
indicates the guaranteed bandwidth in bits per second for uplink 
IP flows. The measurement units for Guaranteed-UL-Bit-Rate are 
bits per second. 


4.2.10. QoS Traffic Selector 


This attribute, QoS-Traffic-Selector, includes the parameters used to 
match packets for a set of IP flows. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. 


When a QoS option that includes the QoS-Traffic-Selector also 
includes any one or more of the attributes Allocation-Retention- 
Priority (Section 4.2.5), Aggregate-Max-DL-Bit-—Rate (Section 4.2.6), 
Aggregate-Max-UL-Bit-Rate (Section 4.2.7), Guaranteed-DL-Bit-Rate 
(Section 4.2.8), and Guaranteed-UL-Bit-Rate (Section 4.2.9), then 
those included attributes are to be enforced at a flow level, and the 
traffic selectors present in the QoS-Traffic-Selector attribute 
identify those target flows. Furthermore, the DSCP marking in the 
QoS option is to be applied only to a partial set of the mobile 
node’s IP flows, and the traffic selectors present in the QoS- 
Traffic-Selector attribute identify those target flows. 
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o Type: 10 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 


o TS Format: An 8-bit unsigned integer indicating the Traffic 
Selector Format. The values are allocated from the "Traffic 
Selector Format" namespace for the traffic selector sub-option 
defined in [RFC6089]; those defined in [RFC6089] are repeated here 
for clarity. Value (0) is reserved and MUST NOT be used. When 
the value of the TS Format field is set to (1), the format that 
follows is the IPv4 Binary Traffic Selector specified in 
Section 3.1 of [RFC6088], and when the value of TS Format field is 
set to (2), the format that follows is the IPv6 Binary Traffic 
Selector specified in Section 3.2 of [RFC6088]. 


o Traffic Selector: variable-length field for including the traffic 
specification identified by the TS format field. 


4.2.11. QoS Vendor-Specific Attribute 


This attribute is used for carrying vendor-specific QoS attributes. 
The interpretation and the handling of this option are specific to 
the vendor implementation. 


This attribute can be included in the Quality-of-Service option 
defined in Section 4.1, and it is an optional attribute. There can 
be multiple instances of this attribute with different sub-type 
values present in a single QoS option. 
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o Type: 11 


o Length: The length of the attribute in octets, excluding the Type 
and Length fields. 


o Reserved: This field is unused for now. The value MUST be 
initialized by the sender to 0 and MUST be ignored by the 
receiver. 

o Vendor ID: The Vendor ID is the SMI (Structure of Management 
Information) Network Management Private Enterprise Code of the 
TANA-maintained "Private Enterprise Numbers" registry [SMI]. 

o Sub-Type: An 8-bit field indicating the type of vendor-specific 
information carried in the option. The namespace for this sub- 
type is managed by the vendor identified by the Vendor ID field. 

4.3. New Status Code for Proxy Binding Acknowledgement 


This document defines the following new status code value for use in 
Proxy Binding Acknowledgement message. 


CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request): 
179 


4.4. New Notification Reason for Update Notification Message 


This document defines the following new Notification Reason value for 
use in Update Notification message. 


QOS_SERVICE_REQUEST (QoS Service Requested): 5 
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4.5. New Status Code for Update Notification Acknowledgement Message 


This document defines the following new status code value for use in 
Update Notification Acknowledgement message. 


CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request): 
130 


5. Protocol Considerations 
5.1. Local Mobility Anchor Considerations 


o The conceptual Binding Cache entry data structure maintained by 
the local mobility anchor, described in Section 5.1 of [RFC5213], 
can be extended to store a list of negotiated Quality-of-Service 
requests to be enforced. There can be multiple such entries, and 
each entry must include the Service Request Identifier, DSCP 
value, and the attributes defined in Section 4.2. 


LMA Receiving a QoS Service Request: 


o On receiving a Proxy Binding Update message with an instance of 
the Quality-of-Service option included in the message and the 
Operational Code field of the Quality-of-Service option set to 
QUERY, then the local mobility anchor includes all the Quality-of- 
Service option(s) reflecting the currently negotiated QoS Service 
Requests for that mobility session in the response message. The 
Operational Code field in each of the Quality-of-Service 
option(s), which is included in the response message, is set to 
RESPONSE. 


o On receiving a Proxy Binding Update message with one or more 
instances of the Quality-of-Service option included in the message 
and the Operational Code field set to ALLOCATE, the local mobility 
anchor processes the option(s) and determines if the QoS Service 
Request for the proposed QoS Service Request(s) can be met. Each 
instance of the Quality-of-Service option represents a specific 
QoS Service Request. This determination to accept the request(s) 
can be based on policy configured on the local mobility anchor, 
available network resources, or other considerations. 


o If the local mobility anchor can support the proposed QoS Service 
Requests in entirety, then it sends a Proxy Binding 
Acknowledgement message with a status code value of (0). 


* The message includes all the Quality-of-Service option 


instances copied (including all the option content) from the 
received Proxy Binding Update message. The local mobility 
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anchor assigns a Service Request Identifier to each Service 
Request and sets the SR-ID field of each included Quality-of- 
Service option accordingly. 


* The Operational Code field in each of the Quality-of-Service 
option(s) is set to RESPONSE. 


* The local mobility anchor should enforce the Quality-of-Service 
rules for all the negotiated QoS Service Requests on the mobile 
node’s uplink and downlink traffic. 


o If the local mobility anchor cannot support any of the requested 
QoS Service Requests in entirety, it rejects the request and sends 
a Proxy Binding Acknowledgement message with the status code value 
set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service 
Request). 


* Since the local mobility anchor cannot support the requested 
QoS services for that mobile node, the Proxy Binding 
Acknowledgement message will not include any Quality-of-Service 


options. This serves as an indication to the mobile access 
gateway that QoS services are not supported for that mobile 
node. 


* The denial of a QoS Service Request MUST NOT result in removal 
of the mobility session for that mobile node. 


o If the local mobility anchor can support QoS services for the 
mobile node, but only with lower quality values than indicated in 
the QoS attributes of a received QoS option or only for some of 
the received QoS Service Requests, the local mobility anchor 
includes the QoS option for the supported QoS Service Requests in 
the Proxy Binding Acknowledgement message with an updated set of 
QoS attributes. 


* If the local mobility anchor cannot support some of the 
received QoS Service Requests for that mobile node, then the 
Quality-of-Service option for these QoS Service Requests is not 
included in the Proxy Binding Acknowledgement message. This 
serves as an indication to the mobile access gateway that a 
particular QoS Service Request is not supported for that mobile 
node. This includes the case where the attributes in a QoS 
option have conflicting requirements, for example, Per-Session-— 
Agg-Max-UL-Bit-Rate is lower than Guaranteed-UL-Bit-Rate. 


* The local mobility anchor includes only QoS options in the 
Proxy Binding Acknowledgement message for supported QoS 
attributes. The contents of each option (including the QoS 
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attributes) reflect the QoS service parameters that the local 
mobility anchor can support for that mobile node. The local 
mobility anchor sets the values of each supported QoS attribute 
according to the level of QoS it can support for the mobile 
node. The Service Request Identifier in each of the included 
QoS options is set to a value of (0). The Operational Code 
field in each of the included Quality-of-Service option(s) is 
set to NEGOTIATE. This serves as an indication for the mobile 
access gateway to resend the Proxy Binding Update message with 
the revised QoS parameters. 


LMA Sending a QoS Service Request: 


(0) 


The local mobility anchor, at any time, can initiate a QoS Service 
Request for a mobile node by sending an Update Notification 
message [RFC7077]. The Notification Reason in the Update 
Notification message is set to a value of QOS_SERVICE_REQUEST, and 
the Acknowledgement Requested (A) flag is set to a value of (1). 


* New QoS Service Request: 


+ The message includes one or more instances of the Quality- 
of-Service option. Each instance of the option will include 
one or more QoS attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to ALLOCATE. 


+ The Service Request Identifier is set to the allocated 
value. 


+ The DSCP field in the Traffic Class (TC) field is set to the 
requested DSCP value. 


* Modification of an existing QoS Service Request: 


+ The message includes one or more instances of the Quality- 
of-Service option with the QoS attributes reflecting the 
updated values in the attributes and the updated list of 
attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to MODIFY. 


+ The Service Request Identifier is set to a value that was 
allocated for that QoS Service Request. 
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+ The DSCP field in the Traffic Class (TC) field is set to the 
requested DSCP value. 
Deletion of an existing QoS Service Request: 


+ The message includes the Quality-of-Service option(s) with 
the relevant QoS attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to DE-ALLOCATE. 


+ The Service Request Identifier is set to a value that was 
allocated for that QoS Service Request. 


+ The DSCP field in the Traffic Class (TC) field is set to the 
DSCP value associated with that request. 


Query for the previously negotiated QoS Service Requests: 


+ The message includes a single instance of the Quality-of- 
Service option without including any QoS attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to QUERY. 


+ The Service Request Identifier is set to a value of (0). 


+ The DSCP field in the Traffic Class (TC) field is set toa 
value of (0). 


o Handling a Response to the QoS Service Request: 


* 


Liebsch, 


If the received Update Notification Acknowledgement [RFC7077] 
message has the Status Code field set to a value (0), the local 
mobility anchor should enforce the Quality-of-Service rules for 
the negotiated QoS parameters on the mobile node’s uplink and 
downlink traffic. 


If the received Update Notification Acknowledgement message has 
the Status Code field set to a value 
CANNOT_MEET_QOS_SERVICE_REQUEST, the local mobility anchor 
applies the following considerations: 


+ The denial of a QoS Service Request results in removal of 
any QoS state associated with that request. 
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+ If the message did not include any Quality-of-Service 
option(s), then it is an indication from the mobile access 
gateway that QoS services are not enabled for the mobile 
node. 


+ If the Operational Code field in the Quality-of-Service 
option is set to a value of NEGOTIATE and the message 
includes one or more instances of the Quality-of-Service 
option, but the option contents reflect a downgraded/revised 
set of QoS parameters, then the local mobility anchor MAY 
choose to agree to proposed QoS Service Request by resending 
a new Update Notification message with the updated Quality- 
of-Service option(s). 


General Considerations: 


(0) 


Any time the local mobility anchor removes a mobile node's 
mobility session by removing a Binding Cache entry [RFC5213] for 
which QoS resources have been previously allocated, those 
allocated resources are released. 


Any time the local mobility anchor receives a Proxy Binding Update 
with HI hint = 3 (inter-MAG handover), the local mobility anchor 
when sending a Proxy Binding Acknowledgement message includes the 
QoS option(s) for each of the QoS Service Requests that are active 
for that mobile node. This allows the mobile access gateway to 
allocate QoS resources on the current path. This is relevant for 
the scenario where a mobile node performs a handover to a new 
mobile access gateway that is unaware of the previously negotiated 
QoS services. 


Mobile Access Gateway Considerations 


The conceptual Binding Update List entry data structure maintained 
by the mobile access gateway, described in Section 6.1 of 
[RFC5213], can be extended to store a list of negotiated Quality- 
of-Service requests to be enforced. There can be multiple such 
entries, and each entry must include the Service Request 
Identifier, DSCP value and the attributes defined in Section 4.2. 


MAG Receiving a QoS Service Request: 


(0) 


On receiving an Update Notification message with one or more 
instances of the Quality-of-Service option included in the 
message, the mobile access gateway processes the option(s) and 
determines if the QoS Service Request for the proposed QoS Service 
Request (s) can be met. Each instance of the Quality-of-Service 
option represents a specific QoS Service Request. This 
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determination to accept the request(s) can be based on policy 
configured on the mobile access gateway, available network 
resources, or other considerations. 


o If the mobile access gateway can support the proposed QoS Service 
Requests in entirety, then it sends an Update Notification 
Acknowledgement message with a status code value of (0). 


* 


The message includes all the Quality-of-Service option 
instances copied (including all the option content) from the 
received Update Notification message. However, if the 
Operational Code field in the request is a QUERY, then the 
message includes all the Quality-of-Service option(s) 
reflecting the currently negotiated QoS Service Requests for 
that mobility session. 


The Operational Code field in each of the Quality-of-Service 
option(s) is set to RESPONSE. 


The mobile access gateway should enforce the Quality-of-Service 
rules for all the negotiated QoS Service Requests on the mobile 
node’s uplink and downlink traffic. 


o If the mobile access gateway cannot support any of the requested 
QoS Service Requests in entirety, then it rejects the request and 
sends an Update Notification Acknowledgement message with the 
status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet 
QoS Service Request). 


* 


Liebsch, 


The denial for QoS Service Request MUST NOT result in removal 
of the mobility session for that mobile node. 


The Update Notification Acknowledgement message may include the 
Quality-of-Service option(s) based on the following 
considerations. 


+ If the mobile access gateway cannot support QoS services for 
that mobile node, then the Quality-of-Service option is not 
included in the Update Notification Acknowledgement message. 
This serves as an indication to the local mobility anchor 
that QoS services are not supported for that mobile node. 


+ If the mobile access gateway can support QoS services for 
the mobile node, but only with lower quality values than 
indicated in the QoS attributes of a received QoS option, 
the mobile access gateway includes the QoS option in the 
Update Notification Acknowledgement message with an updated 
set of QoS attributes. The mobile access gateway sets the 
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values of each QoS attribute according to the level of QoS 
it can support for the mobile node. The mobile access 
gateway includes only QoS options in the Update Notification 
Acknowledgement message for supported QoS attributes. If 
the mobile access gateway receives one or multiple QoS 
options, whose QoS attributes are not supported, it omits 
these QoS options in the Update Notification Acknowledgement 
message. This includes the case where the attributes ina 
QoS option have conflicting requirements, for example, Per- 
Session-Agg-Max-UL-Bit-—Rate is lower than Guaranteed-UL-Bit-— 
Rate. The contents of each option (including the QoS 
attributes) reflect the QoS service parameters that the 
mobile access gateway can support for that mobile node. The 
Operational Code field in each of the Quality-of-Service 
option(s) is set to NEGOTIATE. This serves as an indication 
to the local mobility anchor to resend the Update 
Notification message with the revised QoS parameters. 


MAG Sending a QoS Service Request: 


o The mobile access gateway, at any time, can initiate a QoS Service 
Request for a mobile node by sending a Proxy Binding Update 
message. The QoS Service Request can be initiated as part of the 
initial Binding registration or during Binding re-registrations. 


* 


* 
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New QoS Service Request: 


+ 


The message includes one or more instances of the Quality- 
of-Service option. Each instance of the option will include 
one or more QoS attributes. 


The Operational Code field in each of the Quality-of-Service 
option is set to ALLOCATE. 


The Service Request Identifier is set to a value of (0). 


The DSCP value in the Traffic Class field reflects the 
requested DSCP value. 


Modification of an existing QoS Service Request: 


+ 


The message includes one or more instances of the Quality- 
of-Service option with the QoS attributes reflecting the 
updated values in the attributes and the updated list of 
attributes. 


The Operational Code field in the Quality-of-Service option 
is set to MODIFY. 
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+ The Service Request Identifier is set to a value that was 
allocated for that QoS Service Request. 


+ The DSCP field in the Traffic Class (TC) field is set to the 
requested DSCP value. 


Deletion of an existing QoS Service Request: 


+ The message includes the Quality-of-Service option(s) with 
the relevant QoS attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to DE-ALLOCATE. 


+ The Service Request Identifier is set to a value that was 
allocated for that QoS Service Request. 


+ The DSCP field in the Traffic Class (TC) field is set to the 
DSCP value associated with that request. 


Query for the previously negotiated QoS Service Requests: 


+ The message includes a single instance of the Quality-of- 
Service option without including any QoS attributes. 


+ The Operational Code field in the Quality-of-Service option 
is set to QUERY. 


+ The Service Request Identifier is set to a value of (0). 


+ The DSCP field in the Traffic Class (TC) field is set toa 
value of (0). 


o Handling a Response to the QoS Service Request: 


* 


Liebsch, 


If the received Proxy Binding Acknowledgement message has the 
Status Code field set to a value of (0), the mobile access 
gateway should enforce the Quality-of-Service rules for the 
negotiated QoS parameters on the mobile node’s uplink and 
downlink traffic. 


If the received Proxy Binding Acknowledgement message has the 
Status Code field set to a value of 
CANNOT_MEET_QOS_SERVICE_REQUEST, the mobile access gateway 
applies the following considerations. 


+ The denial of a QoS Service Request results in removal of 
any QoS state associated with that request. 
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+ If the message did not include any Quality-of-Service 
option(s), then it is an indication from the local mobility 
anchor that QoS services are not enabled for the mobile 
node. 


+ If the Operational Code field in the Quality-of-Service 
option is set to a value of NEGOTIATE and the message 
includes one or more instances of the Quality-of-Service 
option, but the option contents reflect a downgraded/revised 
set of QoS parameters, then the mobile access gateway MAY 
choose to agree to proposed QoS Service Request by resending 
a new Proxy Binding Update message with the updated Quality- 
of-Service option. 


* General Considerations: 


+ There can be more than one QoS Service Request in a single 


message. If so, the message includes an instance of a 
Quality-of-Service option for each of those Service 
Requests. Furthermore, the DSCP value is different in each 


of those requests. 


+ Any time the mobile access gateway removes a mobile node’s 
mobility session by removing a Binding Update List entry 
[RFC5213] for which QoS resources have been previously 
allocated, those allocated resources are released. 


6. QoS Services in Integrated WLAN-3GPP Networks 
6.1. Technical Scope and Procedure 


The QoS option specified in this document can provide the equivalent 
level of QoS information defined in 3GPP, which is used to enforce 
QoS policies for IP flows that have been established while the mobile 
node is attached to WLAN access or moved from 3GPP to WLAN access. 
The QoS classification defined by the 3GPP specification [TS23.207] 
[TS29.212] is provided by Differentiated Services techniques in the 
IP transport network. The QoS classification used in the IP 
transport network is further translated to WLAN QoS-specific 
techniques in the WLAN access using appropriate WLAN QoS 
specifications [IEEE802.1laa-2012] [WMM1.2.0]. The details are 
described in Appendix A and Appendix B. 


Figure 6 illustrates a generalized architecture where the QoS option 
can be used. The QoS policies could be retrieved from a Policy 
Control Function (PCF), such as defined in current cellular mobile 
communication standards, which aims to assign an appropriate QoS 
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class to a mobile node’s individual flows. Alternatively, more 
static and default QoS rules could be made locally available, e.g., 
on a local mobility anchor, through administration. 


Non-cellular access Cellular Core Network Cellular 


| 
(e.g., WLAN) | (e.g., EPC) Access 
| (e.9., 
| +----------- + EUTRAN) 
| PCF 
(e.g.,PCRF) 
+----+ | +----- +----- + 
|wiFi] (I) | | 
| AP |---+ +---+---+ | | ((0)) 
+----+ | |wiFi AR| | PMIPv6 +----- + +---+ | 
+----+ (MAG) +=| | LMA |=====|MAG+-- | 
| WLC | | tunnel haa + +---+ | 
+----+ +------- + // 
|WiFi|---+ | // 
| AP | | // 
posse (II) || // 
+-----—- + | // 
+----+ +------ + |WiFi AR // 
|WiFi+----+ WLC +------ + (MAG) |=|=======// 
| AP | | | | o] 
+----+ +-----—- + +-----—- + | 
A s | 
| | | 
4+------------ + 


QoS inter-working 


Figure 6: Architecture for QoS Inter-Working between Cellular Access 
and Non-Cellular Access 


During a mobile node’s handover from cellular access to non-cellular 
access, e.g., a wireless LAN (WLAN) radio access network, the mobile 
node’s QoS policy rules, as previously established on the local 
mobility anchor for the mobile node’s communication through the 
cellular access network, are moved to the handover target mobile 
access gateway serving the non-cellular access network. Such a non- 
cellular mobile access gateway can have an access-technology-specific 
controller or function co-located, e.g., a Wireless LAN Controller 
(WLC), as depicted in option (I) of Figure 6. Alternatively, the 
access-specific architecture can be distributed, and the access- 
technology-specific control function is located external to the 
mobile access gateway, as depicted in option (II). In this case, the 
mobile access gateway and the access-technology-specific control 
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function (e.g., the WLC) must provide some protocol for QoS inter- 
working. Details of such inter-working are out of the scope of this 
specification. 


6.2. Relevant QoS Attributes 


The QoS Option shall at least contain a DSCP value being associated 
with IP flows of a mobility session. The DSCP value should 
correspond to the 3GPP QoS Class Index (QCI), which identifies the 
type of service in terms of QoS characteristics (e.g., conversational 
voice, streaming video, signaling, and best effort); more details on 
DSCP and QCI mapping are given in Appendix A. Optional QoS 
information could also be added. For instance, in order to comply 
with the bearer model defined in 3GPP [TS23.203], the following QoS 
parameters are conveyed for each PMIPv6 mobility session: 


o Default, non-GBR bearer (QCI=5-9) 
* DSCP=(BE, AF11, AF21, AF31, AF32) 
* Per-MN AMBR-UL/DL 
* Per-Session AMBR-UL/DL {S=1,E=1} 
* AARP 
APN (Access Point Name) is provided via the Service Selection ID 
defined in [RFC5149]. If APN is not interpreted by Wi-Fi AP, the 
latter will police only based on Per-MN AMBR-UL/DL (without Per- 
Session AMBR-UL/DL) on the Wi-Fi link. 
o Dedicated, GBR bearer (QCI=1-4) 
* DSCP=(EF, AF41) 
*  GBR-UL/DL 
*  MBR-UL/DL 
* AARP 
* TS 


Wi-Fi AP will perform the policy enforcement with the minimum bit 
rate=GBR and the maximum bit rate=MBR. 
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o Dedicated, non-GBR bearer (QCI=5-9) 
* DSCP=(BE, AF11, AF21, AF31, AF32) 
* Per-MN AMBR-UL/DL 
* Per-Session AMBR-UL/DL {S=1,E=1} 
* AARP 
* -TS 


If APN is not interpreted by Wi-Fi AP, it will police based only 
on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi 
link. 


If DSCP values follow the 3GPP specification and deployment, the code 
point can carry intrinsically additional attributes according to 
Figure 7 in Appendix A. 


For some optional QoS attributes, the signaling can differentiate 
enforcement per mobility session and per IP flow. For the latter, as 
long as the AMBR constraints are met, the rule associated with the 
identified flow(s) overrules the aggregated rules that apply per 
mobile node or per mobility session. Additional attributes can be 
appended to the QoS option, but their definition and specification is 
out of scope of this document and are left as considerations for 
actual deployment. 


7. IANA Considerations 
IANA has completed the following actions: 


o Action-1: This specification defines a new mobility option, the 
Quality-of-Service (QoS) option. The format of this option is 
described in Section 4.1. The type value 58 for this mobility 
option has been allocated from the "Mobility Options" registry at 
<http://www.iana.org/assignments/mobility-parameters>. 


o Action-2: This specification defines a new mobility attribute 
format, the Quality-of-Service attribute. The format of this 
attribute is described in Section 4.2. This attribute can be 
carried in the Quality-of-Service mobility option. The type 
values for this attribute are managed by IANA in a new registry, 


the "Quality-of-Service Attribute Registry". This registry is 
maintained under the "Mobile IPv6 parameters" registry at 
<http://www.iana.org/assignments/mobility-parameters>. This 


specification reserves the type values listed below. All other 
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values (12 - 254) are unassigned and may be assigned by IANA using 
the Specification Required policy [RFC5226]. The Designated 
Expert reviewing the value assignment is expected to verify that 
the protocol extension follows the Proxy Mobile IPv6 architecture 
and does not raise backward-compatibility issues with existing 


deployments. 

+ + + + 
|Value| Description | Reference | 
+ + + + 
| o | Reserved | RFC 7222 | 
+ + + 
| 1 | Per-MN-Agg-Max-DL-Bit-Rate | RFC 7222 | 
+ + + 
| 2 | Per-MN-Agg-Max-UL-Bit-Rate | RFC 7222 | 
+ + + 
| 3. | Per-Session-Agg-Max-DL-Bit-Rate | RFC 7222 | 
+ + + 
| 4 | Per-Session-Agg-Max-UL-Bit-Rate | RFC 7222 | 
+ + + 
|5 | Allocation-Retention-Priority | RFC 7222 | 
+ + + 
| 6 | Aggregate-Max-DL-Bit-Rate | RFC 7222 

+ + + 
ee | Aggregate-Max-UL-Bit-Rate | RFC 7222 | 
+ + + 
| 8 | Guaranteed-DL-Bit-Rate | RFC 7222 

+ + + 
| 9 | Guaranteed-UL-Bit-Rate | RFC 7222 

+ + + 
| 10 | QoS-Traffic-Selector | RFC 7222 | 
+ + + 
| 11 | QoS-Vendor-Specific-Attribute | RFC 7222 | 
+ + + 
| 255 | Reserved | RFC 7222 | 
+ + + 
o Action-3: This document defines a new status code, 


CANNOT_MEET_QOS_SERVICE_REQUEST (179), for use in Proxy Binding 
Acknowledgement messages, as described in Section 4.3. This value 
has been assigned from the "Status Codes" registry at 
<http://www.iana.org/assignments/mobility-parameters>. 


o Action-4: This document defines a new Notification Reason, 
QOS_SERVICE_REQUEST (5), for use in Update Notification messages 
[RFC7077] as described in Section 4.4. This value has been 
assigned from the "Update Notification Reasons Registry" at 
<http://www.iana.org/assignments/mobility-parameters>. 
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o Action-5: This document defines a new status code, 
CANNOT_MEET_QOS_SERVICE_REQUEST (130), for use in Update 
Notification Acknowledgement messages [RFC7077] as described in 
Section 4.5. This value has been assigned from the "Update 
Notification Acknowledgement Status Registry" at 
<http://www.iana.org/assignments/mobility-parameters>. 


8. Security Considerations 


The Quality-of-Service option defined in this specification is for 
use in Proxy Binding Update, Proxy Binding Acknowledgement, Update 
Notification, and Update Notification Acknowledgement messages. This 
option is carried in these messages like any other mobility header 
option. [RFC5213] and [RFC7077] identify the security considerations 
for these signaling messages. When included in these signaling 
messages, the Quality-of-Service option does not require additional 
security considerations. 
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A.1. Mapping Tables 
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Information When Implementing 3GPP QoS in IP Transport 


Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34] 
as follows. 


+ + + + + 
| QCI | Traffic Class | DiffServ Per-Hop-Behavior | DSCP | 
+ + + + + 
| 1 | Conversational | EF |101110| 
+ + + 
| 2 | Conversational | EF |101110| 
+ + + 
| 3 | Conversational | EF |101110| 
+ + + 
| 4 | Streaming | AF41 |100010| 
+ + + 
| 5 | Interactive | AF31 |011010| 
+ + + 
| 6 | Interactive | AF32 |011100| 
+ + + 
| 7 | Interactive | AF21 |010010| 
+ + + 
| 8 | Interactive | AF11 |001010| 
+ + + 
| 9 | Background | BE | 000000 | 
+ + + 


Figure 7: QCI/DSCP Mapping Table 


Mapping between QoS attributes defined in this document and 3GPP QoS 


parameters is as follows. 


Liebsch, 


et al. 


Standards Track 


[Page 47] 


RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 


+ + + + 
|Section| PMIPV6 QoS | 3GPP Qos 

| | Attribute | Parameter. | 
+ + + + 
| 4.2.1 | Per-MN-Agg-Max-DL-Bit-Rate | UE AMBR-DL | 
4+------- 4------------------------------- 4------------- + 
| 4.2.2 | Per-MN-Agg-Max-UL-Bit-Rate | UE AMBR-UL | 
4+------- 4------------------------------- 4+------------- + 

4.2.3 |Per-Session-Agg-Max-DL-Bit-—Rate] APN AMBR-DL 
Flags: (S=1, E=1) 

4+------- 4------------------------------- 4------------- + 
| 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL | 
| | Flags: (S=1, E=1) | | 
4+------- 4------------------------------- 4+------------- + 
| 4.2.5 | Allocation-Retention-Priority | ARP | 
4+------- 4------------------------------- 4+------------- + 
| 4.2.6 |  Aggregate-Max-DL-Bit-Rate | MBR-DL | 
4+------- 4------------------------------- 4------------- + 
| ae | | Aggregate-Max-UL-Bit-Rate | MBR-UL | 
4+------- 4------------------------------- 4+------------- + 
| 4.2.8 | Guaranteed-DL-Bit-Rate | GBR-DL | 
4+------- 4------------------------------- 4------------- + 
| 4.2.9 | Guaranteed-UL-Bit-Rate | GBR-UL 
4+------- 4------------------------------- 4------------- + 
| 4.2.10] QoS-Traffic-Selector | TFT 
4+------- 4------------------------------- +------------- + 


Figure 8: QoS Attributes and 3GPP QoS Parameters Mapping Table 
A.2. Use Cases and Protocol Operations 


The following subsections provide example message flow charts for 
scenarios where the QoS option extensions will apply as described in 
Section 6.1 to the protocol operation for QoS rules establishment 
(Appendices A.2.1 and A.2.2) and to modification (Appendix A.2.3). 


A.2.1. Handover of Existing QoS Rules 


In Figure 9, the MN is first connected to the LTE network with a 
multimedia session, such as a video call, with appropriate QoS 
parameters set by the Policy Control Function. Then, the MN 
discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it, 
provided that Wi-Fi access has a higher priority when available. Not 
only is the session continued, but the QoS is also maintained after 
moving to the Wi-Fi access. In order for that to happen, the LMA 
delivers the QoS parameters according to the bearer type on the 3GPP 
access to the MAG via the PMIPv6 signaling with the QoS option 


Liebsch, et al. Standards Track [Page 48] 


RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 


(OC=ALLOCATE, SR-ID, QoS attributes, etc.). The equivalent QoS 
treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi 
link. 
+-------- + 
[Policy | 
[Control | 
|Function| 
+---4+----+ 
+----+ +------- + ae 
+--+ |LTE | —_—_ | sew | | PGW | 
|mnv|~~|enB | | | | (LMA) | 
+--+ 4----+ +------- + //+-------- + 
: // 
: // 
V +----+ +------- + PMIPv6 // 
+--+ |WiFi| | WLC |========= 
|MN|~~| AP | | (MAG) | tunnel 
+--+ 4----+ +------- + 


Figure 9: Handover Scenario (from LTE to WLAN) 
Figure 10 shows an example of how the QoS rules can be conveyed and 


enforced between the LMA and MN in the case of a handover from 3GPP 
access to WLAN access. 
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+--+ +--+ +--—+ +--—+ 
| MN | | AP | |MAG | | LMA | 
+--+ +--+ +--—+ +--—+ 
| | | | To |data 
|+--detach | | cellular<-==data[DSCP]==-|<---- 
+--=Sattach==--- + | access [QoS rules] 


| | -INFO [MNattach] ->| 
| | ------- PBU [handover] ------ > | 


| <--PBA[QoS option(OC=1 )]-- 
|<-INFO[QoSrules]-| 


| 

| 

| 

| Apply Establish Update 

| mapped MN’s uplink MN’s downlink 

| QoS rules DSCP rules DSCP rules 
+ + 

| | | | 

| | (B) | (A) |data 

veer E A E E qe 

| | | |data 

Fa ss -->data [DSCP] ---> | -=======data [DSCP ] =======->|---> 

| (C) (D) 


A): Apply DSCP at link to AP 

(B): Enforce mapped QoS rules to access technology 

C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or 
validate MN-indicated OC and apply DSCP on the AP-MAG link 
according to QoS rules 

(D): Validate received DSCP and apply DSCP according to QoS rules 


Figure 10: Handover of QoS Rules 
A.2.2. Establishment of QoS Rules 


A single operator has deployed both a fixed access network anda 
mobile access network. In this scenario, the operator may wish a 
harmonized QoS management on both accesses, but the fixed access 
network does not implement a QoS control framework. So, the operator 
chooses to rely on the 3GPP policy control function, which is a 
standard framework to provide a QoS control, and to enforce the 3GPP 
QoS policy on the Wi-Fi access network. The PMIP interface is used 
to realize this QoS policy provisioning. 


The use case is depicted on Figure 11. The MN first attaches to the 


Wi-Fi network. During the attachment process, the LMA, which may 
communicate with Policy Control Function (using procedures outside 
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the scope of this document), provides the QoS parameters to the MAG 
via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e., PBA). 
Subsequently, an application on the MN may trigger the request for 

alternative QoS resources, e.g., by use of the WMM-API (Wi-Fi 


Multimedia - API). The MN may request that traffic resources be 
reserved using L2 signaling, e.g., sending an Add Traffic System 
(ADDTS) message [IEEE802.11-2012]. The request is relayed to the 


MAG, which includes the QoS parameters in the QoS option 
(OC=ALLOCATE) on the PMIP signaling (i.e., the PBU initiated upon 
flow creation). The LMA, in coordination with the PCF, can then 
authorize the enforcement of such QoS policy. Then, the QoS 
parameters are provided to the MAG via the QoS option (OC=ALLOCATE, 
SR-ID, QoS attributes, etc.) in the PMIP signaling, and the 
equivalent QoS treatment is provided towards the MN on the Wi-Fi 


link. 
| 
| 
| +-------- + 
| |Policy | 
| [Control | 
|Function| 
+---+----+ 
| | 
| +---+----+ 
toreng perancis + PMIPv6 | | PGW | 
+--+ |WiFi| | wie |========|=| (LMA) 
[N|] AP | | (MAG) | tunnel eee + 
+--+ +----+ afm oat 4 
| 
Wi-Fi Access | 
Network | Cellular 
| Network 
| 


Figure 11: QoS Policy Provisioning 


Figure 12 shows an example of how the QoS rules can be conveyed and 
enforced between the LMA and MN in the case of initial attachment to 
WLAN access. 
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+--+ +--+ +---+ +-—-+ 

| MN | | AP | ------------- | MAG | ----------------------- | LMA | 

+--+ +--+ +---+ +-—-+ 
| | | | 
| | | | 
+----attached---+ | [QoS rules] 
| | | 

new session | (E) | (F) |data 
----data[QC]-->|---data[DSCPa] -—-> | -======data [DSCPb] =======—> | ---> 


—-PBU[update,QoS option]--> 
| | (ReReg) (OC=1) Validate and 
| | add QoS rule 


| 
| |<----PBA[QoS option]----| 
| |<-INFO[QoSrules]-| (OC=1, SR-ID) [QoS rules’ ] 
| | | | 
Apply Establish 
adapted MN’s uplink 
| QoS rules DSCP rules 
| | | | 
| | | | 
| | | |data 
<--data[QC]-—--- |<---data [DSCP] --- | <-======data [DSCP ] ========- | <---- 
| | | |data 
|---data [QC] ---> |-->data [DSCP] ---> | -=======data [DSCP ] =======->|---> 


(E): AP may enforce uplink QoS rules according to priority class 
set by the MN 

(F): MAG can enforce a default QoS class until the local mobility 
anchor classifies the new flow (notified with PBA) or the mobile 
access gateway classifies new flow and proposes the associated 
QoS class to the local mobility anchor for validation (proposed 
with PBU, notification of validation result with PBA) 


Figure 12: Adding New QoS Service Request for MN-Initiated Flow 
A.2.3. Dynamic Update to QoS Policy 


A mobile node is attached to the WLAN access and has obtained QoS 
parameters from the LMA for that mobility session. Having obtained 
the QoS parameters, a new application, e.g., IP Multimedia Subsystems 
(IMS) application, gets launched on the mobile node that requires 
certain QoS support. 
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The application on the mobile node initiates the communications via a 
dedicated network function (e.g., IMS Call Session Control Function). 
Once the communication is established, the application network 
function notifies the PCF about the new IP flow. The PCF function in 
turn notifies the LMA about the needed QoS parameters identifying the 
IP flow and QoS parameters. LMA sends an Update Notification message 
[RFC7077] to the MAG with the Notification Reason value set to 
QOS_SERVICE_REQUEST. On receiving the Update Notification message, 
the MAG completes the PBU/PBA signaling for obtaining the new QoS 
parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes, 
etc.). The MAG provisions the newly obtained QoS parameters on the 
access network to ensure the newly established IP flow gets its 
requested network resources. 


Upon termination of the established IP flow, the application function 
again notifies the PCF function to remove the established QoS 
parameters. The PCF notifies the LMA to withdraw the QoS resources 
established for that voice flow. The LMA sends an Update 
Notification message to the MAG with the "Notification Reason" value 


set to "FORCE-REREGISTRATION". On receiving this Update Notification 
Acknowledgement message, the MAG completes the PBU/PBA signaling for 
removing the existing QoS rules (OC=DE-ALLOCATE, SR-ID). The MAG 


then removes the QoS parameters from the corresponding IP flow and 
releases the dedicated network resources on the access network. 


Appendix B. Information When Implementing PMIP-Based QoS Support with 
IEEE 802.11le 


This section shows, as an example, the end-to-end QoS management with 
a 802.1le-capable WLAN access link and a PMIP-based QoS support. 


The 802.1le, or Wi-Fi Multimedia (WMM), specification provides 
prioritization of packets for four types of traffic, or access 
categories (ACs): 


Voice (AC_VO): Very high-priority queue with minimum delay. Time- 
sensitive data such as VoIP and streaming mode are automatically 
sent to this queue. 


Video (AC_VI): High-priority queue with low delay. Time-sensitive 
video data is automatically sent to this queue. 


Best effort (AC_BE): Medium-priority queue with medium throughput 
and delay. Most traditional IP data is sent to this queue. 


Background (AC_BK): Lowest-priority queue with high throughput. 
Bulk data that requires maximum throughput but is not time- 
sensitive (for example, FTP data) is sent to the queue. 
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The access point uses the 802.1le indicator to prioritize traffic on 
the WLAN interface. On the wired side, the access point uses the 
802.1p priority tag and DSCP. To allow consistent QoS management on 
both wireless and wired interfaces, the access point relies on the 
802.1le specification, which defines mapping between the 802.1le 
access categories and the IEEE 802.1D priority (802.1p tag). The 
end-to-end QoS architecture is depicted in Figure 13, and the 802.1le 
/802.1D priority mapping is shown in the following table: 


4+----------- 4------------------ + 
| 802.1e AC | 802.1D priority | 
4+----------- 4------------------ + 
| ac_vo | 7,6 | 
4+----------- 4+------------------ + 
| AC_VI | 5A | 
4+----------- 4+------------------ + 
| AC_BE | 0,3 | 
4+----------- 4------------------ + 
| AC_BK | 2,1 | 
4+----------- 4+------------------ + 
+ + +----- + 
DSCP/802.1p | PDP | 
mapping table +----- + 
+ + PEP | 
vi +---+---+ | 
`. |WiFi AR| PMIPv6 +----- + 
- + (MAG) + | LMA | 
| wic | tunnel +----- + 
+------- + PEP 
| 
==Video== 802.1p/DSCP 
==Voice== | 
== B.E.== +----+ 
+----+ |WLAN| PEP 
| MN |----802.11e----| AP | 
+----+ +----+ 


Figure 13: End-to-End QoS Management with 802.1le 


When receiving a packet from the MN, the AP checks whether the frame 
contains 802.1le markings in the L2 header. If not, the AP checks 
the DSCP field. If the uplink packet contains the 802.1le marking, 
the access point maps the access categories to the corresponding 
802.1D priority as per the table above. If the frame does not 
contain 802.1le marking, the access point examines the DSCP field. 
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If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e., 
802.1D priority). This mapping is not standardized and may differ 
between operators; a mapping example is given in the following table. 


+------------------—- +-------- +------------ + 
| Type of traffic | 802.1p | DSCP value | 
+------------------- +-------- +------------ + 
| Network Control | 7 | 56 

+------------------- +-------- +------------ + 
| Voice | 6 | 46 (EF) | 
+------------------—- +-------- +------------ + 
| Video (i; = | 34 (AF 41) | 
+------------------—- +-------- +------------ + 
| Voice Control | 4 | 26 (AF 31) | 
+------------------—- +-------- +------------ + 
| Background Gold | 2 | 18 (AF 21) | 
+------------------—- +-------- +------------ + 
| Background Silver | 1 | 10 (AF 11) | 
+------------------—- +-------- +------------ + 
| Best Effort | 0,3 | 0 (BE) 

+------------------—- +-------- +------------ + 


The access point prioritizes ingress traffic on the Ethernet port 
based on the 802.1p tag or the DSCP value. If the 802.1p priority 
tag is not present, the access point checks the DSCP/802.1p mapping 
table. The next step is to map the 802.1p priority to the 
appropriate egress queue. When 802.11le support is enabled on the 
wireless link, the access point uses the IEEE standardized 802.1p/ 
802.1le correspondence table to map the traffic to the appropriate 
hardware queues. 


When the 802.1le-capable client sends traffic to the AP, it usually 
marks packets with a DSCP value. In that case, the MAG/LMA can come 
into play for QoS renegotiation and call flows depicted in Appendix A 
apply. Sometimes, when communication is initiated on the WLAN 
access, the application does not mark upstream packets. If the 
uplink packet does not contain any QoS marking, the AP/MAG could 
determine the DSCP field according to traffic selectors received from 
the LMA. Figure 14 gives the call flow corresponding to that use 
case and shows where QoS tags mapping does come into play. The main 
steps are as follows: 


(A): During the MN attachment process, the MAG fetches QoS 


policies from the LMA. After this step, both the MAG and LMA are 
provisioned with QoS policies. 
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(B): The MN starts a new IP communication without making IP 
packets with DSCP tags. The MAG uses the traffic selector to 
determine the DSCP value; it then marks the IP packet and forwards 
within the PMIP tunnel. 


(C): The LMA checks the DSCP value with respect to the traffic 
selector. If the QoS policies are valid, the LMA forwards the 
packet without renegotiating the QoS rules. 


(D): When receiving a marked packet, the MAG, the AP, and the MN 
use 802.1le (or WMM), 802.1lp tags, and DSCP values to prioritize 
the traffic. 


+--+ +--+ +---+ +-—-+ 
| MN | | AP | |MAG | | LMA | 
+--+ + —+ +--+ +---+ 
(A) | ----attach----- | ---------------- > | ----------- PBU---------- >| 
|<-------------- |---------------- |<----PBA[QoS option]----- | 
: ; [QoS rules] [QoS rules] 
(B). : , | 
new session | | | 
—---data[]---->|----data[]------ > | -======data [DSCP] ======—> 
(C) | | | Validate QoS rule 
| | | [= 
| | | <======data [DSCP ] ======== | <---- 
| | | | 
mapping 
(D) DSCP/802.1p 
| |<----data-------- | 
| | [802.1p/DSCP] | | 
| | | 
| mapping | | 
802.1p/802.1le 
<--data [WMM] --- | 
| | 
---data [WMM] -->|------ data------ > | =======data [DSCP ] =======> | -- -> 
| 
| 


| 
| | [802.1p/DScP] | 
| 


Figure 14: Prioritization of a Flow Created on the WLAN Access 
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Appendix C. Information When Implementing with a Broadband Network 
Gateway 


This section shows an example of QoS interworking between the PMIPv6 
domain and the broadband access. The Broadband Network Gateway (BNG) 
or Broadband Remote Access Server (BRAS) has the MAG function, and 
the CPE (Customer Premise Equipment) or Residential Gateway (RG) is 
connected via the broadband access network. The MN is attached to 
the RG via, e.g., Wi-Fi AP in the broadband home network. In the 
segment of the broadband access network, the BNG and RG are the 
Policy Enforcement Point (PEP) for the downlink and uplink traffic, 
respectively. The QoS information is downloaded from the LMA to the 
BNG via the PMIPv6 with the QoS option defined in this document. 
Based on the received QoS parameters (e.g., DSCP values), the 
broadband access network and the RG provide appropriate QoS treatment 
to the downlink and uplink traffic to/from the MN. 


+----- + 
| PDP | 
+----- + 
PEP | 
+------- + | 
| BNG/ | PMIPv6 +----- + 
| BRAS + | LMA | 
| (MAG) | tunnel +----- + 
+------- + PEP 
Broadband ( | ) 
Access ( DSCP ) 
Network ( | ) 
+----- + 
+----+ | CPE | PEP 
| mn |------------- | /RG | 
tsss Broadband, +=ss== + 


Home Network 


Figure 15: End-to-End QoS Management with the Broadband Access 
Network 


In the segment of the broadband access network, QoS mapping between 
3GPP QCI values and DSCP described in Section 6.2 is applied. In the 
segment of the broadband home network, if the MN is attached to the 
RG via Wi-Fi, the same QoS mapping as described in Appendix B can be 
applied. 
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